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DIGITAL . ACTIVE ftPVERTmw? 

^ BACKGROUND OF THE INVEHTION 

5 The recent rapid growth of information 

applications on international public packet-switched 
computer networks such as the Internet suggests that 
public computer networks have the potential to establish 
a new kind of open marketplace for goods and services. 

10 Such a marketplace could be created with a network sales 
system that comprises a plurality of buyer and merchant 
computers r means for the users of the buyer computers to 
display digital advertisements from the merchant 
computers , and means for the users to purchase products 

is described by the advertisements. 

A network based sales system will need to allow 
users to preview products at little or no cost, and will 
need to make a large number of product advertisements 
available in a convenient manner. In addition , the 

20 shopping system will need to include easy-to-use 

facilities for a user to purchase desired products using 
a merchant independent payment method. In addition the 
network sales will need to allow new buyers and merchants 
to enter the market. 

25 A central requirement for a marketplace is a 

payment mechanism, but at present no merchant independent 
payment mechanism is available for computer networks that 
permits users to utilize conventional financial 
instruments such as credit cards , debit cards, and demand 

30 deposit account balances. We expect that both retail 

payment and wholesale payment mechanisms will be required 
for networks, with consumers using the retail mechanism 
for modest size purchases, and institutions using the 
wholesale mechanism for performing settlement between 

35 trading partners. For wide acceptance the retail 

mechanism will need to be a logical evolution of existing 
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credit-card, debit-card, and Automated Clearing House 
facilities, while for acceptance the wholesale mechanism 
will need to be an evolved version of corporate 
electronic funds transfer. 
s These problems of have been approached in the 

past by network based sales systems wherein, for example, 
each merchant maintains an account for each user. A user 
*ust establish an account with each merchant in advance 
in order to be able to utilise the merchant. The prior 
XQ art network based sales systems are not designed to allow 
users to use their existing credit card and demand 
deposit accounts for payment, nor are they designed to 
allow for programs to be included in digital 

advertisements. 

According, therefore, it is a primary objective 
of this invention to provide a user interactive network 
sales system in which the user can freely use any 
merchant of choice and utilize existing financial 
instruments for payment. Other objects include a network 
2 o sales system which provides a high-quality user 

interface, which provides users with a wide variety and 
iarge volume of advertisements, which is easily 
extensible to new services, and which is easily expanded 
Tnew applications within the existing infrastructure of 

25 the system. 

Still other objects of the invention are to 

provide a network payment system that will •*** i »V 
payment orders and remove part of the risk of fraud from 

30 An unavoidable property of public computer 

networks is that they are comprised of switching, 
transmission, and host computer components controlled by 
many individuals and organizations. Thus it is 
impossible for a network payment system to depend upon a 

„ specified minimum required degree of software, hardware, 
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and physical security for all of the components in a 
public network. For example, secret keys stored in a 
given user's personal computer can be compromised, 
switches can be tampered with to redirect traffic, and 
s transmission facilities can be intercepted and 
manipulated. 

The risk of performing retail payment in a public 
network is compounded by statutes that make a payment 
system operator in part liable for the security lapses of 

10 its users. Existing Federal statutes in the united 

States, including the Electronic Funds Transfer Act and 
the consumer Credit Protection Act, require the operator 
of a payment mechanism to limit consumer liability in 
many cases. Payment system operators may have other 

is fiduciary responsibilities for wholesale transactions. 
Similar responsibilities exist in other countries for 
retail and wholesale transactions. 

In existing credit card payment systems, a credit 
card's issuing bank takes on the fraud risk associated 

20 with misuse of the card when a merchant follows 
established card acceptance protocols. Acceptance 
protocols can include verifying a card holder's signature 
on the back of their card and obtaining authorization for 
payments over a certain value. However, in network based 

25 commerce a merchant can not physically examine a 
purchasers credit card, and thus the fraud risk may 
revert to the merchant in so called "card not present 1 * 
transactions* Many merchants can not qualify to take 
this risk because of their limited financial resources* 

30 Thus the invention is important to allow many merchants 
to participate in network based commerce ♦ 

Other objects of the invention include utilizing 
existing financial instruments such as credit cards, 
debit cards , and demand deposit accounts for merchant 

as payments. 



PAGE 50/97 * RCVD AT S/4/2006 3:42:55 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-3/5 * DN1S:2738300 * CSID:703«487799 * DURATION (mm-ss):24-16 



Fax sent by : 7838467799 



88-84-86 83:53 



?g: 51/97 



Existing network payment systems do not connect 
to the financial system for authorization and are not 
compatible with conventional financial instruments. 
Existing network payment systems include the simple 
s Network Payment Protocol [Dukach, S. , SNPP: A Simple 
Network Payment Protocol, MIT Laboratory for Computer 
Science, Cambridge, MA, X993.), sirbu's internet Billing 
Server [Sirbu, M. A. , Internet Billing Service Design and 
Prototype implementation. Information Networking Program, 
io Carnegie-Mellon University, 1993), and NetCash [Medvinsy, 
G., and Newman, B. C. , NetCash: A Design for Practical 
Electronic Currency on the Internet, Proc. 1st ACM Conf . 
on Comp. and Comm. Security, November, 1993]. 

A further object of the invention is to allow 
15 users in an untrusted network environment to use 
conventional financial instruments without requiring 
modification to existing financial system networks. 

The following definitions apply to the present 
invention. A principal is a person, company, 
20 institution, or other entity that is authorized to 

transact business as part of a network payment system. A 
payment order describes the identity of a sender, a 
payment amount, a beneficiary, and a sender unique once. 
A sender is a principal making a payment. A beneficiary 
25 is a principal to be paid by the payment system. A 
sender unique nonce is an identifier that is used only 
once by a given sender. An example of sender unique 
nonces are unique times tamps. An external account is an 
account that can be used to settle a payment order for 
30 either a sender or a beneficiary in the external 

financial system. Examples of external accounts include 
demand deposit accounts and credit card accounts. An 
external device is a physical object that is kept in the 
possession of a user for the purpose of identifying the 
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A network payment system is a service that: 
authorizes and executes digital payment orders that are 
backed by external accounts. A payment system 
authenticates a payment order 9 checks for sufficient 
5 funds or credit , and then originates funds transfer 
transactions to carry out the payment order. A payment 
system acknowledges acceptance or rejection of a payment 
order* More than one payment system may exist on a 
given network, and a given payment system may operate on 

10 more than one host to increase its reliability, 

availability, and performance. An authenticates is a 
digital value that is appended to a payment order and 
becomes part of the payment order that authenticates the 
payment order as genuine. 

15 SUMMARY OF THE INVENTION 

The invention relates to a network sales system 
for enabling users to purchase products using a plurality 
of buyer computers that communicate over a network with a 
plurality of merchant computers. Each merchant computer 

20 has a database of digital advertisements* Each digital 
advertisement includes a price and a product abstract* 
Buyer computers request, display, and respond to digital 
advertisements from merchant computers. Users can 
purchase products with their buyer computers after they 

25 have specified an account to pay for the purchase. A 

network payment service is used to authorize the purchase 
before merchant fulfillment is performed. 

In a particular aspect of the invention, the 
merchant computer can request account information when it 

30 is not provided by the buyer computer* in another 

aspect of the invention, the buyer computer can present 
to a merchant a pre-authorized payment order that is 
obtained from a network payment system. 

In another aspect of the invention, an electronic 

35 sales system contains digital advertisements that include 
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programs. The programs are executed on behalf of a user 
by a buyer computer, and can lead to a purchase request 
directed to a merchant computer that performs product 
fulfillment. 

s m another aspect of the invention a network payment 

system executes payment order*. A payment order includes 
a sender, a beneficiary, a payment amount, and a nonce 
identifier. A payment order is signed by a client 
computer with an authenticator that is checked by the 

10 payment system. Payment orders are backed by accounts 
in the banking system, and are authorized by the network 
payment system by sending messages into a financial 
authorization network that knows the status of these 
accounts. The payment system accomplishes settlement by 

X3 sending messages into an existing financial system 
network. 

In another aspect, payment orders are 
authenticated based on the delivery address they specify, 
in another aspect, the payment system will specify in its 
20 authorization legal delivery addresses. In another 
aspect, authenticators for payment orders are based on 
one-time transaction identifiers that are known only to 
the user and the payment system. In another aspect, 
payment orders for a given sender are only accepted from 
25 certain client computer network addresses. In another 
aspect, the network payment system sends messages into a 
financial authorization system in real-time before the 
network payment system will authorize a payment order. 

Other objects, features, and advantages of the 
invention will appear from the following description 
taken together with the drawings in which: 

Figure 1 is a block diagram of a typical network 
sales system in accordance with the invention; 
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Figure 2 is a screen snapshot of a buyer computer 
display of an overview page from a merchant computer; 

Figure 3 is a screen snapshot of a buyer computer 
display of a page of digital advertisements from a 
5 merchant computer; 

Figure 4 is a screen snapshot of a buyer computer 
display of an account query page; 

Figure 5 is a screen snapshot of a buyer computer 
display of a fulfillment page; 
10 Figure 6 is a flow chart illustrating the 

processing of a sale between a buyer computer and a 
merchant computer; 

Figure 7 is a flow chart illustrating the 
alternate processing of payment order means for obtaining 
is missing payment information; 

Figure 8 is a screen snapshot of a buyer computer 
display of an overview page from a merchant computer that 
contains a query input by the user; 

Figure 9 is a screen snapshot of a buyer computer 
20 display of digital advertisements in response to a user's 
query; 

Figure 10 is a screen snapshot of a buyer 
computer screen of a purchase confirmation; 

Figure 11 is a screen snapshot of a buyer display 
25 of a fulfillment page like Figure 5; 

Figure 12 is a flow chart illustrating an 
alternate processing of a sale between a buyer computer 
and a merchant computer where a payment order is pre- 
authorized; 

30 Figure 13 is a block diagram of a typical network 

payment system in accordance with the invention; 

Figure 14 is a flow chart illustrating the 
authentication, authorization, and settlement of a 
payment order; 
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Figure 15 is a flow chart illustrating an 
alternate processing of the authentication and 
verification of a payment order where transaction 
identifiers are used; and 

5 Figure 16 is a flow chart illustrating an 

alternate processing of the authorization of a payment 
order where real-time approval from the financial 
authorization network may not be obtained. 

r r»e mr iTn M OF A p ^ TT rnr.&P PRFFERBFT) EMBOPIMEffl 

10 A network sales system 200 as shown in Figure l 

employs a network 67 to interconnect a plurality of buyer 
computers 61 and 62, merchant computers 63 and 64, each 
merchant computer with respective digital advertisement 
databases 65 and 66, and a payment computer 68. A user 

15 of the system employs a buyer computer to retrieve 
advertisements from the merchant computers, and to 
, purchase goods of interest. A payment computer is used 

to authorize a purchase transaction. 

A digital advertisement includes a product 

20 description and a price. In digital advertisement 
database 65 prices and descriptions may be stored 
separately, and one price may apply to many product 

descriptions. 

in an alternate embodiment, the network sales 
2S system further includes external devices that are kept in 
the possession of users so that the users can 
authenticate themselves when they use a buyer computer. 

The software architecture underlying the 
particular preferred embodiment is based upon the 
30 hypertext conventions of the World Wide Web. Appendix A 
describes the Hypertext Markup Language (HTML) document 
format used to represent digital advertisements, Appendix 
B describes the HTML forms fill out support in Mosaic 
2.0, Appendix C is a description of the Hypertext 
35 Transfer Protocol (HTTP) between buyer and merchant 
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computers, and Appendix D describes how documents are 
named with Uniform Resource Locators (URLs) in the 
network of computers, k document is defined to be any 
type of digital data broadly construed, such as 
5 multimedia documents that include text, audio, and video, 
and documents that contain programs* 

Figure 2 shows an overview screen that has been 
retrieved from a merchant computer by a buyer computer 
and displayed by the buyer computer. It includes links 

10 1, 2, and 3 that when activated by a user cause the 

buyer's computer to take specified actions. In the case 
of link i, the document shown in Figure 3 is retrieved 
from a merchant computer and displayed. In the case of 
link 2, a short audio segment is retrieved from a 

is merchant computer and played. In the case of link 3, the 
query that can be entered into the query dialog box 4 is 
sent to a merchant computer, and a document is retrieved 
from the merchant computer and displayed * 

Figure 3 shows a document that contains three 

20 digital advertisements. The digital advertisements have 
been retrieved from the merchant computer after the 
activation of link 3. The merchant computer may set the 
prices contained in the advertisements based on the on 
the identity of the user as determined, for example, by 

25 the network address of the requesting buyer computer. 
The document includes links 5, 6, and 7 that are used to 
purchase the products described by the advertisements. 
For example, if link 5 is activated the missing payment 
information document shown in Figure 4 is retrieved from 

30 the merchant computer and displayed. 

Figure 4 is a missing payment information 
document that is used to gather user account information 
for the requested purchase in an HTML form. Radio 

hnt^fnnc P Q 1 ft 11 1 O arc ncori color*- m moavvc «^ 
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number, dialog box 14 is used to enter an optional 
authenticator Cor the account, purchase button 15 is used 
to send the account information to the merchant computer 
and proceed with the purchase, link 16 is used to abort 
5 the purchase and return to the document shown in Figure 
2, and dialog box 17 is used to enter optional user 
information that i© associated with the purchase and 
ultimately used by a financial institution as part of a 
textual billing identifier for the purchase transaction. 

10 If provided, this additional information is included in 
the payment order for the purchase. 

Figure 5 is a fulfillment document 18 that is 
produced once valid account information is provided to 
the missing payment information document in Figure 4 and 

15 purchase button 15 is activated* 

Figure 6 is a flowchart that more fully describes 
the information flow in the purchase transaction shown in 
Figures 2 to 5. An initial user inquiry 19 from 
activating link 1 results in the HTTP request 20 for a 

20 specific document with a specified URL. The URL 
specifies the name of the merchant computer. The 
merchant computer retrieves the document given the WXL at 
21, and returns it to the buyer computer at 22. The 
buyer computer displays the resulting HTML document at 

25 23. When the user activates link 5, an HTTP request 25 
is sent to the merchant computer requesting the document* 

In an alternate embodiment , document 22 is 
executed at 23 as a program. A program is defined as a 
set of instructions that can exhibit conditional behavior 

30 based upon user actions or the environment of the buyer 
computer. As is known to those skilled in the art, there 
are many techniques for representing programs as data. 
The program can be interpreted or it can be directly 
executed by the buyer computer. The program when 

35 executed will cause the buyer computer to interact with 
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the user leading to the user purchase request 24, and the 
purchase message 25. 

The merchant computer then attempt© to construct 
a payment order at 26 using the information it has 
s gathered about the user. The buyer computer may have 
previously supplied certain credentials using fill out 
forms or other account identification means such as 
providing the network address of the buyer computer in 
the normal course of communication. If the buyer 

lo computer is able to construct a complete payment order at 
26 the payment order is sent to a payment computer for 
authorisation at 27. If a payment order can be 
constructed , processing continues at 28. 

Alternatively , the buyer computer may construct 

is the payment order at 24 and send it to the merchant 

computer at 25. in this case, the payment order assembly 
steps at 26, at the merchant computer , may only need to 
forward the payment order from the buyer computer. 
A payment order includes user account 

20 information , merchant account information, an amount, and 
a nonce identifier that has not been previously used for 
the same user account. Variation* of payment orders can 
be constructed P including payment orders that specify 
user or merchant identifiers in place of account 

25 information, payment orders that specify at valid time 
period, payment orders that specify foreign currencies, 
and payment orders that include comment strings. Part of 
the process of constructing a payment order is creating a 
corresponding authenticator using one of the 

30 authenticator methods described below. 

In the illustrated embodiment of Figures 3 and 4, 
the merchant computer does not have sufficient 
information to construct a payment order at 26 and thus 
at 33 (Figure 7) constructs and returns a missing payment 

35 information document in response to request 25. 
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Operation 33 includes in the constructed document 
appropriate form fields based on what information the 
merchant computer has already collected from the user. 
The document is returned to the buyer computer at 34 and 
is displayed at 35. When the user presses the purchase 
button 15, the contents of the form are transmitted to 
the merchant computer, at 36, to a specific URL name, 
using an HTTP request. Based on the supplied form 
fields, the merchant computer constructs a complete 
payment order. Alternatively, the buyer computer »ay 
construct the payment order at 35 and send it to the 
merchant computer as part of step 36. In this case, the 
payment order assembly steps 37 at the merchant computer 
simply passes on the payment order from the buyer 
15 computer. The payment order is sent to the payment 
computer in a message at 38. 

in either case, the flowchart continues in Figure 
6 where the payment computer checks the authorization of 
the payment order at 29. If the payment system 
20 authorizes the request, an. authorization message at 29 is 
returned to the buyer computer, and the merchant computer 
checks at 30 that the authorization message came from the 
payment computer using the authenticator mechanism 
described below. Assuming that the authorization message 
25 is valid, the merchant computer performs fulfilment at 
30, returning the purchased product in response at 31. 
in our example in Figure 5 the response at 31 is document 
18 that was the logical target of link 5. If the payment 
system does not authorize the payment order then response 
30 31 is a rejection of the user's purchase request. 

In an alternate embodiment, step 30 can encrypt 
the document using a key that is known to the buyer 
computer. As is known to those skilled in the art, the 
key can be communicated to the merchant computer using 
as convention key distribution protocols. In this manner 
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the document will be protected from disclosure to other 
users • 

The fulfillment step at 30 can alternatively 
schedule a physical product to be shipped via ordinary 
5 mail or other means. This can be accomplished by 

updating a fulfillment request database or by sending a 
message to a shipping system* In this case the response 
at 31 is a confirmation that the product has been 
scheduled to ship. In this way the network sales system 

10 can implement an electronic mail order system* 

Figures 8, 9, 10, and 11 show a second example 
that uses query based access to digital advertisements* 
It is assumed that the previous example was used by the 
user immediately before at the same buyer computer. 

is Figure 8 shows the overview screen where the 

query "movie review" has been entered into dialog box 39. 
When the user activates process button 40/ the merchant 
searches databases as described by the URL attached to 
button 40, and creates a response document as shown in 

20 Figure 

Figure 9 shows digital advertisements 39, 40, 41, 
42, 43, and 44 that were found in response to the query 
initiated by button 40. A scroll bar 45 shows that there 
are additional digital advertisements that are not shown. 

25 When link 46 is activated, the missing account 

information document shown in Figure 10 is returned by 
the merchant computer* 

Figure 10 shows that the merchant computer has 
partial information on the buyer's account* Message 47 

30 shows that the merchant computer already knows the 

buyer's account number. Purchase button 48 will send the 
optional user reference string in dialog box 50 to the 
merchant computer described by the OKI* behind button 48 
and purchase the product corresponding to digital 
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advertisement 39. Cancel link 49 will return the user to 
the document shown in Figure 2. 

When purchase button 48 is activated, a document 
51 is sent by the merchant computer ana displayed by the 
buyer computer as shown in Figure 11. 

Figure 12 shows an alternative method of 
processing a sales transaction. In this method when the 
user requests a purchase at 52, the buyer computer 
constructs a payment order at S3 and sends it for 
approval to the payment computer at 54. The payment 
computer authorises the payment order at 55; and when the 
payment order is authorized, returns an unf orgable 
certificate at 56 that the payment order is valid. Means 
of creating such unforgable certificates are described in 
authenticator method number one below. If at step 55 the 
payment order is not authorized, a rejection message is 
sent at 56 and the sales transaction is terminated. 

The buyer computer then proceeds at 57 to send a 
pre-authorized purchase request to the merchant computer. 
The unforgable certificate 56 is included in a purchase 
message at 57 that is sent at 58 to the merchant 
computer. Based upon the pre-authorized payment order 
the merchant computer performs fulfillment at 59 and 
returns the product at 60. In a variation, the merchant 
computer at 59 checks to ensure the payment order has not 
been previously used. This can be accomplished by 
checking with a payment computer or maintaining a 
merchant computer database of previously accepted payment 
orders. The unforgable certificate created at step 56 
does not need to include the user account information. 
This variation is useful if the user wishes to make 
purchases and remain anonymous to the merchant. 
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A Network Payment system 

A network payment system 300 as shown in Figure 
13, employs a public packet-switched network 69 to 
interconnect a plurality of client computers 70 ana 71, 
5 and a plurality of payment computers such as 72, each 
payment computer having an account database 73, a 
settlement database 74, an authorized address database 
75, a sender credential database 76, a financial system 
interface 77, and a real-time authorization interface 78. 

10 The interfaces 77 and 78 may be implemented by a single 
communications line. 

In an alternate embodiment, the network payment 
system further includes external devices that are kept in 
the possession of users so that the users can 

i$ authenticate themselves when they use a buyer computer* 
Account database 73 maintains temporal spending 
amounts, such as the amount spent in the current day, and 
also maintains temporal spending limits. The account 
database may also maintain a translation between 

20 principal identifiers and external account identifiers * 
Settlement database 74 records committed payment orders 
along with any authorization information for the orders 
that was obtained from interface 78* Address database 75 
maintains for each sender a list of authorized buyer 

25 computer and delivery addresses. Credential database 76 
maintains a list of credentials for principals and 
information that can be used to authenticate principals . 

Figure 14 is a flowchart that describes the 
operation of the payment system* A client computer 71 

30 constructs a payment order at 79, and computes and adds 
an authenticated to the payment order at 80. The payment 
order is sent at 81 to a payment computer, where the 
authenticator is verified at 82 to ensure that the 
payment order was originated by the sender it describes. 
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Below we present different means of implementing 80 and 
82. 

If the payment order is authentic and address 
restrictions are desired, at 83, either or both of the 

s client cojnputer address or the specified delivery address 
can be checked against address database 75. If address 
restrictions are desired and if the addresses in the 
payment order are not in the database, the payment 
computer sends a rejection message to the client 

io computer. Address database 75 specifies, for each 
principal, acceptable client computer addresses and 
delivery addresses. A delivery address can be a network 
address, or a street address for packaged goods. As is 
known in the art, database 75 can include wild-card 

IB specifications and similar techniques to reduce its si2e. 
For example, database 75 could contain an entry for 
principal identifier •*§acme.eom" restricting legal 
delivery addresses to "computer: *.com", "computer: 
cmu.edu", and "surface: *, 34 Main Street, Anytown, USA", 

20 indicating that any user at the company Acme can order 
products to be delivered to the network address at Acme 
or the university cMU, or to anyone at 34 Main street, 

Anytown, USA. 

If payment order address restrictions are not 

25 desired or have been checked, processing continues at 84 
where the payment order is checked for replay and 
temporal spending limits. Replay is checked for by 
making sure that the sender did not previously present a 
payment order with the same nonce by checking en index of 

30 committed payment orders by nonce in settlement database 
74. If nonces are based on time, then a payment order 
that is older than an administratively determined value 
can be rejected out of hand. Time based nonces or 
sequential nonces permit old nonces to be removed from 

3 s the settlement database 74. If a payment order has been 
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previously processed or its nonce is too old, the payment 
order computer sends a rejection message to the client* 

After the payment order passes the replay check r 
temporal spending limits are checked in account database 
S 73. These spending limits can be applied on a per 
sender, per group of senders, and per payment system 
basis to limit fraud risk. The limits can be applied to 
any duration of time, for example a maximum spending 
amount per hour or per day. If the payment order would 

10 violate a spending limit, the payment computer sends a 
rejection message to the client* 

Once the payment order passes the temporal 
spending check at 84, a message is constructed at 85 to 
check that the external account that backs the sender's 

15 payment system account has adequate funds or credit. If 
the sender Identifier in the payment order is not already 
an account number in the external financial system, it is 
translated into a corresponding account number in the 
external financial system using account database 73* A 

20 real-time authorization request message is sent at 86 to 
the external financial system over interface 78* If the 
external financial system approves authorization request 
86, an authorization message is returned at 87* If 
request 86 is not approved, the payment computer sends a 

25 rejection message to the client at 87* 

In a variation of the above described approach, 
processing continues at 95 after 84* At 95 real-time 
authorization is only obtained when the total of a 
sender's payments since the last real-time authorization 

30 reaches a preset value, or the payment order is over a 
preset amount* These preset values can be optionally 
recorded on a per principal basis in database 73 or can 
be administratively determined for all principals. In 
this manner, the number of messages to the external 

35 financial system can be reduced. In addition, the 
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payment system can avoid making real-time authorization 
requests for small payments when the risk is acceptable 
to the payment system operator- If real-time 
authorization is necessary, processing continues at 85 

5 after 95- If real-time authorization is not necessary 
for a request, at 100 the payment order amount is added 
to the sender's total of payments since the last real- 
time authorization in database 73, and processing 
continues at 88. 

10 in another variation after 100 a check is made at 

101 in database 73 to see if a background authorization 
process should be scheduled. A background authorization 
process permits the payment computer to continue its 
normal processing while it checks with the financial 

is authorization network on the sender's account. This 
mechanism can be used to limit payment system risk. If 
the background authorization fails, the account is 
suspended by so updating database 73. If the sender's 
total of payments since last authorization is over a 

20 preset value stored in 73 then a background authorization 
process is scheduled at 102. Otherwise processing 
continues at 88. 

In another variation, at 95 and 101 
authorizations are obtained based on the amount spent 

25 since last authorization and time since lefst 

authorization. 

At 88 the payment order is committed to execution 
and is recorded in settlement database 74. Recorded with 
the payment order in database 74 are portions of 

30 authentication message 87 that show that the payment 
computer contacted the remote financial system. The 
amount of the payment order is added to running temporal 
spending records in database 73, and an authorization 
message is sent to the client computer at 90. The 

as authorization message includes the payment order. In an 
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alternate embodiment, at 90 the authorisation message 
contains a truncated payment order that includes at least 
the payment order's sender and the payment order's unique 
nonce. 

5 In an alternate embodiment, the authorization 

message sent to the client at 90 includes at least one 
legal delivery addresses for the sender as determined 
from database 75* 

Authorisation message 90 must be transmitted in 

10 such a way that the client computer can be sure that it 
came from the payment computer. At 89 a payment system 
specific authenticator is added payment order. At 91 
this authenticator is checked by the client computer » 
The steps at 89 we a dual of step 80, and the steps at 

15 91 are a dual of step 82. The authentication means for 
steps 89 and 91 are described belov. 

Finally, settlement is performed at 92 in the 
external financial system 77 between external accounts 
that correspond to the sender and the beneficiary. If 

20 settlement is accomplished as part of real-time 

authorization at steps 86 and 87, as may occur in a real- 
time debit network, then no other steps need to be taken. 
If settlement is not accomplished as part of the 
authorization process, then financial system messages are 

25 sent to interface 77 to effect settlement. Depending on 
the external accounts involved, these messages may 
include electronic funds transfer messages or automated 
clearinghouse messages. 

In an alternate embodiment, at 92 settlement 

30 messages are sent to reconcile net transfer balances 

between principles on a temporal basis, for example once 
a day* In this embodiment the number of settlement 
messages can be less than the number of payment orders. 

Authenticators may be created and checked using 

35 one of the following methods. The payment computer can 
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use any of the first four methods, and the client 
computer can use any of the methods described. 

In a first method for authenticators, at steps 80 
or 89, a digest of the payment order is signed by the 
5 sending computer using a public-key cryptographic system 
such as RSA. This signature is used as the 
authentieator. As is well known in the art, the signing 
can be accomplished using a private key created from a 
public-key pair, where the signing key is only known by 
10 the signer, and the other public key is known to the 
receiving computer. At the payment computer the public 
key corresponding to each sender is kept in credential 
database 76. The private key for the payment service is 
also kept in database 76. At steps 82 or 91, the 
15 signature of the received message is checked using the 
public key known to the receiving computer. 

in a second method for authenticators, at steps 
80 or 89, a digest of the payment order is signed by the 
sending computer with a private key cryptosystem such as 
20 DES. This signature is used as the authentieator. At 
the payment computer, the private key corresponding to 
each sender is kept in credential database 76. At step 
80, a digest Of the payment order is signed by the client 
computer, and at step 89 a digest of the payment order 
25 with an added approval code is signed by the payment 
computer using the same private key. At steps 82 or 91, 
the signature of the received message is checked using 
the shared private key. 

in a third method for authenticators, at step 80 
so the authentieator is computed by a protected device 

external to the system such as a Smart-Card. A protected 
device is specifically designed to be extremely difficult 
both to replicate and to compromise. In this method, the 
n rrter is communicated at 80 to a smart-card. The 
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order, and then communicates the signature back at 80 to 
be used as an authenticates ♦ A Smart-*Card produced 
authenticator uniquely associates a payment order with 
its creating Smart-Card • This is accomplished by having 
5 the Smart-Card contain a secret key W K" that is used to 
create a digital signature of the payment order. "K" is 
never released outside of the Smart-card* The Smart-Card 
is designed to make it computationally infeasible to 
compute "K" even with possession of the device. Xn this 

10 method, at step 82, a signature checking key from 

database 76 is used to check the authenticator* In an 
alternate embodiment, a user must manually signal their 
acceptance of each payment order on an input device that 
is part of the external device before the authenticator 

IS is created by the external device. 

In a fourth method for authenticators, at steps 
80 or 89, a network address is used as an authenticator. 
At steps 82 or 91, a digest of the payment order is sent 
back to the specified network address along with a random 

20 password. The computer at the specified network address 
must then return the payment order digest along with the 
password* If the network guarantees to deliver messages 
to the proper network address, this method will guarantee 
that the user or computer at the specified network 

25 address approves of the payment order* Assuming that 
network delivery is trusted, this method can be used to 
authenticate a sender computer's network address in a 
payment order. Alternatively, electronic mail can be 
used to send such confirmation messages between a user 

30 and the payment system. 

In a fifth method for authenticators, at step 80, 
the authenticator is produced by an external device that 
produces a sequence of non~predicable transaction 
identifiers that are device specific. The authenticator 

35 is entered by the user into the client computer by 
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reading its display. One such device is described in 
U.S. patent 4,856,062- According to this method, at step 
91, the authenticates can be cheeked using the sender 
specific fixed cede of the device which is kept in 
s database 76. This sequence of steps is also shown in 
Figure 15 at steps 93 and 94. 

in a sixth method for authenticates , at step BO, 
the authenticator is obtained by querying the user for a 
transaction identifier that is the next string from a 
10 physical list of one-time authorization strings. Such as 
list could be produced on a card, and the user can cross 
off authorization strings as they are used. According to 
this method, at step 91, the authenticator is checked 
against the next expected string from the sender using 
is database 76. Database 76 can hold for each sender a list 
of random authorization strings, or can hold a sender 
specific secret key that was used to generate the list of 
authentication strings along with how many strings have 
been used so far. This sequence of steps is also shown 
20 in Figure 15 at 93 and 94. 

In a seventh method for authenticators, at step 
SO the authenticator is a previously obtained personal 
identification number (PIM) for the user. In this method 
in 91 the authenticator is cheeked against the expected 
25 P1H for the sender using database 76. 

as will be obvious to one skilled in the art, any 
of the methods for creating authenticators can be used 
together to increase system security. For example, 
authenticator method six can be used to create an 
30 authenticator based on a transaction identifier, and then 
a payment order including a transaction identifier can be 
given a further authenticator using authenticator method 
one. In this example the resulting authenticators would 
be checked with their respective methods. 
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A digest of a payment order can be created with 
an algorithm such as MD5 [R. Rivest, The MD5 Message- 
Digest Algorithm, HIT Laboratory for Computer Science, 
Network Working Group Request for Comments 1321). 
s Alternatively, a digest can be the entire payment order 
or other functions of the payment order's component 
parts* 

In addition in both the sales and payment systems 
alternate authenticates techniques can be used such as 

10 those described by Voydock and Kent in m Security 

Mechanisms in High-level Network Protocols w , Computing 
Surveys Vol. 15, No* 2, June 1983. As will be 
appreciated by those skilled in the art, two-way 
authenticated byte-stream or remote procedure call 

is interface connections that protect against replay can 
replace our message based authenticators* 

Additions, subtractions, deletions, and other 
modifications of the described embodiment will be 
apparent to those practiced in the art and are within the 

20 scope of the following claims. 
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CLAIMS 

l. A network sales system comprising 
a plurality of buyer computer* and at least one 
merchant computer interconnected by a communications 
network, 

means at each merchant computer tor maintaining 
and providing a database of digital advertisements 
comprising 

means for storing said digital advertisements, 
each digital advertisement including a product abstract, 
means for communicating a digital advertisement 
to a buyer computer over said network in response to a 
network request from said buyer computer, 

means at each buyer computer for requesting, 
displaying, and responding to digital advertisements 

is comprising 

means responsive to a user inquiry for selecting 
a merchant computer and obtaining a digital advertisement 
for a product from said database of advertisements at 
said merchant computer, 

display means for displaying said advertisement, 
purchase means responsive to a user request for 
communicating a purchase message to said merchant 
computer, 

account identification means for transmittxng the 
user's account information to said merchant computer, 
means, at said merchant computer, comprising 
authorization means to authorize said purchase 
message by sending messages into a financial system 
network, 

fulfillment means to send said product to user 
conditional on approval pt said authorization means. 



30 
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2, The network sales system of claim 1 further 
wherein said authorization means at said merchant 
computer comprises 

means for communicating a missing payment 
9 information request message to said buyer computer to 
obtain missing payment information, 

means for receiving said missing payment 
information from said buyer computer , 

means for authorising said purchase message by 
10 sending messages into a financial system network, 

and said account identification means at said 
buyer computer comprises 

means responsive to said missing payment 
information request message to query the user for 
15 additional payment information, 

means to send said additional payment information 
to said merchant computer. 

3, The network sales system of claim 1 further 
wherein said account identification means comprises 

20 means for assembling a payment order, 

means for sending said payment order to a network 
payment system for authorisation, 

and wherein said authorization means comprises 
means for verifying that said payment order has 

25 been previously authorized by said payment system. 

4, An electronic sales system comprising 
means for storing a database of digital 

advertisements, each digital advertisement for a product 
including a program, 
30 means for communicating a digital advertisement 

to a buyer computer, 

means at said buyer computer for displaying and 
responding to said digital advertisement comprising 



PAGE 72/97 * RCVD AT 8/4/2006 3:42:55 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-3/5 * DNIS:273«300 * CSID:703«467799 * DURATION (mm-ss):24-16 



Fax sent by : 7838467799 



WO 95/16971 



88-B4-06 83:59 Pg: 73/97 
PCT/D594/14319 



- 27 - 

response means for sending an 
authorization message to said client computer, 

means for sending at least one message 
into a financial system network to transfer funds from 
5 said sender to said beneficiary* 



6. The network payment system of claim 5 further 
wherein said payment specification means comprises 

means for constructing a payment order r said 
payment order including a delivery address , 
io and said verification means comprises 

means for verifying that said sender originated 
said payment order and checking said delivery address 
against a database of allowed delivery addresses for said 
sender* 

15 7. The network payment system of claim 5 further 

wherein said response means comprises 

means for determining allowed delivery addresses 
for said sender, 

means for sending an authorisation message to 
20 said client computer that includes allowed delivery 
addresses* 



8* The network payment system of claim S further 
wherein said signing means comprises 

means for generating the next expected 
25 transaction identifier for said sender and using it to 
create an authenticator, 

and wherein said verification means comprises 
means for generating the next expected 
transaction identifier for said sender, and 
30 means for verifying that said authenticator was 

created using said transaction identifier. 
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9. The network payment system of claim 5 further 
wherein said signing means comprises 

means for generating an authenticator using an 

external device, 
5 and wherein said verification means comprises 

means for verifying that said authentieator was 
created using said external device. 

10. The network payment system of claim 5 
further wherein said payment specification means 

10 comprises 

means for constructing a payment order from a 
sender, said payment order including a client computer's 
network address, 

and said verification means comprises 
is means for verifying said payment order was 

constructed at said client computer's network address and 
checking said client address against a database of 
allowed client addresses for said sender. 

11. The network payment system of claim 5 
20 further wherein said authorization means comprises 

determination means for determining the necessity 
for real-time authorization, 

means for performing real-time authorization 
conditioned on said determination means. 

2S 12. A method for effecting sales over a network 

sales system having a plurality of buyer computers and at 
least one merchant computer interconnected by a 
communications network, encompassing the steps of 

maintaining and providing a database of digital 
30 advertisements at each merchant computer 

storing said digital advertisements, each digital 
advertisement including a product abstract. 
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communicating a digital advertisement to a buyer 
computer over said network in response to a network 
request from said buyer computer , 

requesting, displaying, and responding at each 
5 buyer computer to digital advertisements comprising the 
steps of 

selecting in response to a user inquiry a 
merchant computer and obtaining a digital advertisement 
for a product from said database of advertisements at 
10 said merchant computer, 

displaying said advertisement, 
communicating in response to a user request a 
purchase message to said merchant computer, 

transmitting the user's account information to 
15 said merchant computer, 

authorizing at said merchant computer said 
purchase message by sending messages into a financial 
system network, and 

sending said product to said user conditional on 
20 approval from said authorizing step. 

13. The network sales method of claim X2 further 
wherein said authorizing step, at said merchant computer, 
comprises the steps of 

communicating a missing payment information 
25 request message to said buyer computer to obtain missing 
payment information, 

receiving said missing payment information from 
said buyer computer, 

authorizing said purchase message by sending 
30 messages into a financial system network, 

and said account identification step at said 
buyer computer comprising the steps of 
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querying the user for additional payment 
information responsive to said biasing payment 
information request message, 

and sending said additional payment information 
5 to said merchant computer. 

14 . The .network sales method of claim 12 further 
wherein said account identification step comprises the 
steps of 

assembling a payment order , and 
10 sending said payment order to a network payment 

system for authorization, 

and wherein said authorization step comprises the 

step of 

verifying that said payment order has been 
15 previously authorized by said payment system. 

15. An electronic sales method comprising the 

steps of 

storing a database of digital advertisements, 
each digital advertisement for a product including a 
20 program, 

communicating a digital advertisement to a buyer 
computer, 

displaying and responding to said digital 
advertisement at said buyer computer comprising the steps 

25 Of 

displaying said digital advertisement by 
executing a portion of said advertisement as a program 
and performing actions as specified by said program, 
communicating a purchase message in response to a user 
30 request to a merchant computer, 

sending at said merchant computer said product to 

user. 
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16 „ A network payment method comprising the 
steps of interconnecting a plurality of client computers 
and at least one payment computer by a public packet 
switched communications network, 
5 performing payment at a client computer 

comprising the steps of 

constructing a payment order from a sender to a 
beneficiary, 

authenticating said payment order as originating 
10 from said sender/ 

sending said payment order to a payment computer, 

and receiving a payment order authorization 
message from said payment computer, 

responding to a payment order message at said 
15 payment computer * comprising the steps of 

verifying that said sender originated said 
payment order, 

sending a message into a financial authorization 
network to verify that said sender has adequate funds or 
20 credit and receiving an authorization in response , 

recording said payment order and authorization in 
a settlement database, 

sending an authorization message to said client 
computer, 

2$ and sending at least one message into a financial 

system network to transfer funds from said sender to said 
beneficiary. 

17* The network payment system of claim 16 
further wherein said constructing step means comprises 
30 the steps of 

constructing a payment order, said payment order 
including a delivery address, 

and said verifying step comprises the steps of 
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verifying that said sender originated ©aid 

payment order , and 

checking said delivery address against a database 
of allowed delivery addresses for said sender* 

5 18- The network payment method of claim 16 

further wherein said second sending step comprises the 
steps of 

determining allowed delivery addresses for said 

sender, 

10 and sending an authorization message to said 

client computer that includes allowed delivery 
addresses* 

19. The network payment method of claim 16 
further wherein said authenticating step comprises the 
IS steps of 

generating the next expected transaction 
identifier for said sender and using it to create an 
authenticator, 

and wherein said verifying step comprises the 

20 steps of 

generating the next expected transaction 
identifier for said sender , 

and verifying that said authenticator was created 
using said transaction identifier. 

2 s 20. The network payment method of claim 16 

further wherein said authentication step comprises the 
step of 

generating an authenticator using an external 

device, 

30 and wherein said verifying step comprises the 

steps of 
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verifying that said authenticates was created 
using said external device. 

21. The .network payment method of claim 16 
further wherein said constructing step comprises the step 
5 of 

constructing a payment order from a sender, said 
payment order including a client computer's network 
address, 

and said verifying step means comprises the steps 

10 of 

verifying said payment order was constructed at 
said client computer's network address, 

and checking said client address against a 
database of allowed client addresses for said sender. 

is 22. The network payment method of claim 16 

further wherein said second sending step comprises the 
steps of 

determining the necessity for real-time 
authorization, 
20 and performing real-time authorization 

conditioned on its determined necessity* 
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HOUSTON- Arriving for a house call at 357 miles above Earth*the astronaut* 
of the space shuttle Endeavor reached out Saturday with a mechanical 
grappling arm and easily snared the Hubble telescope* 

The orbital retrieval paves the way for the .nuttier astronaut, to trsat 
the crippledspaeecraft in five days of the most complex orbital repairs 
yet attempted. 

•Houston, Bndeavorhea afirn handshake with mr. Hubble's telescope,' Col. 
Richard P- Coveyof ths Air Poree, the shuttle eonmandsr, radioed to 
Mission control in Houston after the robotic arm bad grasped the 1.6 
billion telescope. 

The shuttle's successful rendezvous with the orbiting telescope wa$ the 
first major step in a mission that could be fateful to both astronomy and 
KASA 

Installing new mirrors to overcome Hubble'* blurred visionviil return the 
telescope to its full abilities, giving the astronomers a view almost to 
the edge of the universe. Ana such a highly visible success could boost 
the space agency** reputation St t time it is seeking support for building 
an international space station 

Once the 12,5-ton telescope was securely berthed in the oper cargo bay 
Saturday morning, it -a» ready for the astronaut* to begin the first of 
their five space walks eerly Sunday morning 

The schedule calls for Or. Mucgrsve and Dr. Jeffrey A. Hoffman to replace 
failed gyroscopes, two electronic control units and some fuses. 



FIG. 5 



PAGE Ml ' RCVD AT 8/4/2006 3:42:55 PM [Eastern Daylight Time] ' SVR:USPTO-EFXRF-3/5 ' DNIS:2738300 ' CSiD:703S467799 ' DURATION (mm-ss):24-1 6 



Fax sent by : 7838467799 



W09S/16971 



88-84-86 84:82 
PCT/US94/14319 



Pg: 85/97 



6/16 

BUYER MERCHANT PAYMENT 

COMPUTER COMPUTER COMPUTER 



19 User Inquiry 

20 "I Request Advertisements) 
^ 

i 

Retrieve Digital - 
^22 Advertisement(s) 

Digital Advertisements) | 
*m 

I 

Display Digital 23 
Advertisment 

I 

User Requests- — -24 
Purchase 



21 



Construct Payment 27 

Order 1 / 

J Payment Order 

1 28 

1 / 
Authorize Purchase 

Authorization Message I 

29 



31 Perform Fulfillment 

) ' i ^ 

Product 1 30 



FIG. 6 

PAGE >S»7 'RCVDAT SHSOH PM [Etston Daylght TtaK] ' SV^USPTOfFXHF-an* DNIS:273830O ' CSD:70}SM7799 ' DURfflW }mi«s):24-« 



Fax sent by : 7038467799 



WO 95/1*971 



88-84-06 84:82 
PCT/US94/14319 



Pg: 86/97 



7/16 

BUYER MERCHANT PAYMENT 

COMPUTER COMPUTER COMPUTER 

I Purchase 

, Message ^' 



Construct Missing Payment 
mfomiation Request 



Missing Payment 

information Req. 
i ^ 

34 

Query User for' 
Payment tnfbrmation 

I 36 
Missing Payment/ 
Information Message 



37 



I r 

Construct Payment 
Order 

Payment Order 



| _ . _ , _ 38 



FIG- 7 



PAGE 86/97 ' RCVD AT 8/4/2006 3:42:55 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-3/5 * DNI$:2738300 * CSID:7038467799 * DURATION (mm-ss):24*16 



Fax sent by : 7838467799 



88-84-86 84:82 Pg: 87/97 



PCT/CS94/14319 



NCSA Mosaic: Document View 



Fife Options Navigate Annotate 



DOCIimenl Title: | Welcone to Shfe Intormatjaia Bxch&ftgg 
DOCUITient URL: | http://sp*rta.lc».rait.edu>^ifgcrd/ix-l.htal 



TimTsS 









Welcome to The Information Exchange 



Today's Headlines 
Radio Headlines 



Query: 



39 

-L— 



BO vie r»vi»W 



A 

0 



Process ^~40 



|B<cfc| ) Forward | Hom»| |FUIo*d| |Oynj gave A>_j 



Help 




Ctorml flaw Window] tClOn Wtnrfoi 



tfj [ClQi« Window] 



FIG. 8 

PAGE 87/97 * RCVD AT 8/412006 3:42:55 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-3/5 * DNI8:2738300 ' CSID:7038467799 ' DURATION (mm-ss):24*16 



Fax sent by : 7638467799 



WO 95/16971 



08-84-06 04:02 
PCT/US94/14319 



Pg: 88/97 



9/16 



NCSA Mpaatc: Document View 
\£H optio ns Navigate Annotate 

Document Title: | Query ».*»uit« . ™*«» 



Help 



Document URL: | ^, f ^^^^^'^^ 



QUERY RESULTS: movie review 



39 



1. Dae. 2 1W3 MiM P* ii»«»> «H1 ~ u . , 

, _ -i-ite deeply into the drab role or 

In -a Dano-rou. Wo***." %,ln °! "inc in a small CaIUo^U tc». 
Martha Bor«an. * .helped in nocent living in » — « c 

— 40 

S£ »e.,l. Faro (Andi* M.Oow«ll> H t» world. 



45- 



♦Twenty Buck-- follow- * M° 7" rf. tt ._ u _ tiOB *onth« later, Alona the way it 
,„to»-tic Mil- ***** "/^r^'SSrSSa. fr~ all wallw of lif- 
P ».«. S through tha heads of ao«en« ot lnd**iamn» 



«. Nov, 23 1993 «,46 ,48 li— 1 fig 14MW a„a and viol-nca. It 

a perfect World.' a dra»a. i« rated PS 13 lor 
ticeivid 3 and one-half .tare one of •*■» Hollywoode «ar. who 

Clint Kaatwood and Kevin <^V!^^ri£ Parted world.- their 

entertain without aacritiein, artiatxc integrity, I» 

reputations remain intact. ^ , 

— * ' 43 

5. mov. 23 1993 18.«« CS3 line.l raeaived 2. 
C0B0R3B BkLMMinn ■BVrcftXCKB*.- o danee f U-. i« J"»"o 

atari out of •«> - M „*i chri»t*as ahow staoed by the 

A atraightforward record of the ^^J^^^,. wOU i« have eon. 
Haw York city Ballet. -Q.orge Bal.nchi ne ^ SutcracM 

directly to TV if »»t for the participate of 

— — ' " ' 44 

6. Nov. 23 1993 18:46 [60 linaal S1£0 

,. WF RB BACK. A OISOSAOR'3 STO**,- a„ •nx****d feature. 
2 atare out o£ 4.) ^ . -_ t __ animated 'we're Back! A 



42 



is rated C It raeaivad 



b F-^q B inm 5 



««• WtMowl 



FIG. 9 

PAGE 8&V97 * RCVD AT 874/2006 3:42:55 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-3/5 * DNIS:2738300 » CSID:703«467799 * DURATION (mm-ss):24-16 



Fax sent by : 7838467799 



88-84-86 84:82 Pg: 89/97 



W095tt6971 



FCT/US94/14319 



10/16 



NCSA Mosaic: Document View 



File Options Navigate Annotate 



Help 



Document Title: | comira char?« 



Document URL: | htw//gparta.lcg>iDit.e<m>^l£tord/ix^.htAX 




Digital Copyright License Purchase 

In exchange for the specified fee you will be licensed for individual Use of Che 
copyrighted naterial 

Confirm a charge of $1.00 ov your VISA 4262 1501 2000 1466 "-~ 47 
Pure hooe -**48 



Your Reference: 



SO 



A 
□ 



|fl«ok| j Fofw-rd | |7f«n.«| |H»teadj jOpanj 3>v» A»~| 



N»w Window! Clo»» Window 



3 



FIG. 10 



PAGE 89/97 * RCVD AT 8/4I200S 3:42:55 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-3/5 * DNIS:2738300 1 CSID:7038467799 * DURATION (mm-$s):24-16 



Fax sent by : 7038467799 



WO 95/16971 



88-04-06 04:03 
PCnUS94/14319 



Pg: 90/97 



11/16 



51 V 



NCSA Mosaic: Document View 

File 



gpthns Navigate Annotate 



Document Title: | a dahomo ™ *q M ». 

OOCUmeilt URL: | h c W //^rcaac^e d ^i«ord/lx. 6 . ft ca, 



ID 




A DANGEROUS WOMAN 

»y J A WET MASLIH 

The »« York w (copyright 1*9* The new 



priority: R««ul»r 

««»9ory; Brt«eHw"t and fMlt«*« 
VtfbfeCC; BC WOMB* KEVXEW 



PAGE 90197* 



. j. Aft i v inti the drab role 
I, -a parous woman/ Debr. wi »«"S"^ 1 jTU.U California town. 
Mirth* Hor«an, « ahelwredHwoeen* luring la * 

..--.-tino th* storyteller-* int»r»t at a 
Character. lift. *«*ha have a way .«-«lMJ*^ ^ ^ fere th . 
v „ y praei,e point in th.ir llv... it u t» ^ ^ Uk- 

character, peaceful existence ruptnr.d W 
or death or a symbolic coeino of 

oanoer-u. - i. ~» — * " W th " B ' 

Wlt h Mtw r «--scs 2 s ssssrjs. 4 * 1 " 

creates a world ©f «a*«»al chicanery 
proud. 

► .„ neM Barbara »ar.hey>. a rich, beautiful 
Harth* i. taken car. of by -^'^l"! a .tat* 

wilow involved i" *» eXtt *""* i "„ th , m » with . suitable bano. a. th* 

S. of r^frin, h.r irritate. 

i.h niohtuown and thick glaaaee. 
Kartha. a *r«oil. creatur. xn a J 1 * 11 '* £f ^ th . filB iat end, it a. a 

works and will afi 



g f^i BBS S 



N»w Wtagow| CHo»» Window] 



1 i— — eirt 11 

* RCVD AT S/4/2006 3:42:55 PM [Eastern Daylight Time] * SVR:USPTO-EFXRF-3/5 * DNIS:2738300 ft CS1D:70384677d9 * DURATION (mm-ss):24-16 



Fax sent by : 7838467799 



88-84-86 84:83 Pg: 91/97 



WO 95/16971 



PCI7US94/14319 



BUYER 
COMPUTER 

I 



12/16 

MERCHANT 
COMPUTER 



PAYMENT 
COMPUTER 



I 

User Requests' 
Purchase 



.52 



I ^53 
Construct Payment 
Order | 



54 

Payment Order 



55 



Authorization Message 



/ 

Authorize Payment Order 

I 



| 56 

Construct ^57 
Purchase Mesage 
with Authorized 

Payment Order 58 
■ Purchase Message" 

I 

Perform Fulfillment — 59 

Product i 

1 

60 



FIG. 12 



PAGE 91/97 1 RCVD AT 8/4/2006 3:42:55 PM [Eastern Daylight Time] 1 SVR:USPTO-EFXRF-3/5 * DNIS:27^300 * CSID:703S467799 * DURATION (mm-ss):24-16 



Fax sent by : 7838467799 



68-84-86 84:83 Pg: 



WO 95/16971 



PCTAJSM/14319 



13/16 



r 



78 



Real-Time Financial 
Authorization Network 
(Credit Card, Debit Card, 
etc.) 



Client 
Computer 

1 

70 



300 



Financial 
System 
Settlement 
Interface 



i 



Payment 
Computer 



Credential 



Database 



^76 



Hi 



Authorized Client 
and Delivery —75 
Address Database 

Settlement 

Database 

Account Database 
(Limits, Totals, — 73 
Account Numbers) 



Network 




69 



FIG. 13 



PAGE 92S7 ' RCVDAT SflfflMe 3^£SS PM [Esteni Da^ht Tlone] * SVR:U8PT0{F)(RF^S ' DNIS:273t300 ' C9D:703M«779! ' DUUTION ^m-ss|:24-1l 



Fax sent by : 7838467799 



88-04-06 84:83 Pg: 



WO 95/15971 



PCT/US94/14319 



CLIENT 
COMPUTER 

79— Construct Payment Order 



14/16 

PAYMENT 
COMPUTER 



REAL-TIME 
FINANCIAL 
AUTHORIZATION 
NETWORK 



80 Compute and Add 

Authentfcator 



| Payment Order 



81 



I 



82— verify Atithenticator 
I 

83 — Check for Address Restrictions 

I 

84 — Check for Replay and Spending Limits 

85 Construct Message for 

Real-Time Authorization 

Authorization Request 



86 



Authorization Number 



87 



Record Payment Transaction — 88 



90 

/ 

Authorization 

Message 
^ - 



Add Authentfcator to Authorization Message. 



89 



Verify Authorization Authentfcator 
/ 
91 

Perform Settlement 



92 



PAGE 93/97 1 RCVD AT 8/412006 3:42:55 PM [Eastern Daylight Time] * SVR:USPTO£FXRF-3/5 * DNIS:2738300 * CSID:7038467799 1 DURATION (mm-ss):24-16 



Fax sent by : 7838467799 



88-84-86 84:83 Pg: 



WO 95/16971 



PCT/DS94/14319 



CLIENT 
COMPUTER 



15/16 

PAYMENT 
COMPUTER 



REAL-TIME 
FINANCIAL 
AUTHORIZATION 
NETWORK 



Construct Payment Order 

I 

Add Tranasctlon Identifer as 
part of Autherrticator 

| Payment Order 



93 



I 



Verify Authenticate* and 
Confirm Transaction 
Identifer is One Expected 



,94 



I 



FIG. 15 



PAGE 94/97 * RCVD AT 8/4)2006 3:42:55 PM (Eastern Daylight Time] * $VR:USPTO-EFXRF-3/5 * DNIS:2738300 * CSID:7038467799 * DURATION (mm-ss):24-16 



Fax sent hy : 7938467799 



88-84-86 84:83 Pg: 95/97 



WO 95/16971 



PCT/US94/14319 



16/16 



PAYMENT 
COMPUTER 



REAL-TIME 
FINANCIAL 
AUTHORIZATION 
NETWORK 



I 

Check for Replay and Spending Limits 

I 

Real-Time Authorization Necessary? 



95 



No 



100 



Yes 



Update Account Database Construct Message for ^ 96 

Real-Time Authorization 



101 



Schedule Background 
Authorization? 

| Yes 1 No 



Request Background 
Authorization 

/ 1 

102 



97 



Authorization Request 

». 

Authorization Number i 
■+ V 



98 



1 

Record Payment Transaction 

I 



99 



FIG. 16 



PAGE 95/97 ' RCVD AT 8/4/2006 3:42:55 PM [Eastern Daylight Time] ' SVR:USPTO-EFXRF-3/5 « DNI8:2738300 ' CSID:703S467799 ' DURATION (mm-ss):24-16 



Fax sent by : 7838467799 



88-64-86 84:84 Pg: 96/97 



INTERNATIONAL SEARCH REPORT 



In. itional application No. 
PCT/US94/14319 



"Z CLASSIFICATION OF SUBJECT MATTER 
IPC(6) :C06F 157:00 
™^X21£Lf~* CUssificaik,n(l^ .ru, bethel *■»■*. »nd IPC 



B FIELDS SEARCHED _ — u 

Minimum ^-urnentat*. searched (^fiction blfcwed by cla».fi»uo» .jnnbol.) 

U.S. : 564/401. 406.4C8: 340^1533; 380/23.24; 902/1.2.24 



" -— ; . . A^e-utfan » the extent thai such document* are included tt the fields Marched 

Documentation icarchcd other *an minimum documcn?*iKm kj w « 

none 



^ b «„ —.I* duri- *c ^ma,^ ^ ^ of ^ ^ ^. ^ pratAeablc. ^ ^ ^) 
M^lr££ home,2.)sho P 7. e^cTC^hop*. downto^pr^ 



C DOCUMENTS CONSIDERED TO BE RELEVANT 




Y 
Y 
Y 
Y 



US, A, 4,992,940 (DWORKIN) 12 February 1991, see col. 2, 
line's 30-34. 

US, A, 4,775,935 (YOURICK) 4 October 1988, see figures 
5b and 6. 

US, A, 4,935,870 (BURK, JR. ET AL.) 19 June 1990, see 
col. 15. 

US, A, 5,025,373 (KEYSEft, JR. FT AL.) 18 JumlJSI. see 
col. 4, lines 45-58, col. 6, lines 1-25, end col. 8. lines 39- 
45. 



Relevant to claim No- 



1-22 
1*22 
4, 15 
4, IS 



5, 8-9, 16, 19- 
20 



Q<J Further doeuawoto arc lbt*d in the eontiiwatiori Q 



IBoxC Q See pain* fcmily *nnex. 



V 



nr 



Specfcl i,iie»nriM of tM < 

r document puMidud en or ■ 

r imtw daub* od priority chaM « vCl * c ^J' 
cited to etfeblU. tejAibIMM of -y* 

, *b onl dkkNR. mm, eRlpbttoa o* •*« 



*ixim«1 of unMLMlar wfcnranorx Ac dmoas kkiiulMU M ? ao *** 



of pMtkahr itlBveAec; lb* 



coMAkwd with «•* or w*» o*her document*, ■ 
•eta* oowkrtietoft »OTO«*iled bfbsaft 



^to.rpetiowlfi^diitel^lpfcr'i 

Dale of Uw actual compaction of the international search 



r«xuiy 



23 JANUARY 1995 



*<wl m»iHiia *ddrcu of the ISA/US 



Date of mailing of the international search report 

01 MAY 1995 



Authorized Officer g^, \_ ^ 



PAGE 96/97 ' RCVD AT 8(412006 3:42:55 PM [Eastern Daylight Time] ' SVR:USPTO€FXRF-3/5 ' DNIS:2738300 ' CSID:703I!467799 ' DURATION (mm-ss):24-16 



Fax sent by 



7838467799 



88-84-86 84:84 



Pg: 97/97 



INTERNATIONAL SEARCH REPORT 



•national Application No. 
KnYUS*4/l43l9 



C (Continuation). DOCUMENTS CONSIDERED TO BE RELEVANT 



Category* 



Y 
Y 



Citation of document* with indication* where appropriate, of the relevant passages 



US. A, 4,812,628 (BOSTON ET AL.) 14 March 1989, see entire 
disclosure. 

US, A, 4,922,521 (KRIKKE ET AL.) 01 May 1990, see col. 6, 
lines 1-52. 



Relevant to claim No. 



11,22 



6-7, 10, 17-18, 
21 



PAGE 97/97 ' RCVD AT 8/412006 3:42:55 PM [Eastern Daylight Time] ■ SVR:USPTO€F XRF-3/5 1 DNIS:273S300 * CSID:7038467799 * DURATION (mm-ss):24-1 6 ' 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 

BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defect^ in the images include but are not limited to the items checked: 

J2 BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



